The first computers were only able to run a single program at a time. In modern times, however, computers are expected to be able to run several different pieces of software at once. For example, typical multi-tasking operating systems, such as the MICROSOFT WINDOWS family of operating systems, can run several application programs at once on a single machine. A virtual machine monitor (VMM) is to an operating system what a multi-tasking operating system is to an application program: a VMM allows several operating systems to run at once on a single machine.
A VMM enables plural operating systems to run on a single machine by “virtializing” the entire machine. Conventionally, an operating system controls the use of the physical hardware resources of a machine (e.g., the memory, the processor, etc.), and thus the actual hardware of the machine is exposed to the operating system. When a VMM is used, however, the machine's hardware (e.g., devices) are only exposed to the VMM. The VMM, then, exposes “virtual” machine components to the operating systems. The operating systems control the virtual components exposed by the VMM, and the VMM, in turn, controls the actual hardware.
When plural operating systems are running under a VMM, the VMM's design effectively isolates each operating system from every other operating system. Since each operating system interacts only with the unique set of virtual machine components exposed to it by the VMM, none of the operating systems can interact directly with any of the other operating systems. In effect, when plural operating systems run under a VMM, every operating system is completely protected from the actions of every other operating system.
A VMM is useful when it is desired to completely isolate every operating system from every other operating system. However, the design of a VMM has at least the following drawbacks: (1) in some cases, it is not desirable to isolate all of the operating systems from each other, since this isolation denies the operating systems the ability to share useful infrastructure; and (2) since a VMM requires full virtualization of the machine and all of its devices (thereby requiring that the VMM provide its own device driver for every possible device), a VMM is not well suited to an open architecture machine in which an almost limitless variety of devices can be added to the machine.
In particular, a VMM is especially unsuited to the case where there is one “main” operating system that controls most processes and devices on a machine, and where it is desired to run a small, limited-purpose operating system along side the main operating system to perform certain limited tasks. One way to make an operating system “small” or “limited-purpose” is to allow the small operating system to borrow certain infrastructure (e.g., the scheduling facility, the memory manager, the device drivers, etc.) from the “main” operating system. However, since a VMM effectively isolates one operating system from another, this sharing of infrastructure is not practical.
Certain techniques allow operating systems to exist side-by-side on the same machine without the use of a virtual machine monitor. One such technique is to have one operating system act as a “host” for the other operating system. (The operating system that the “host” is hosting is sometimes called a “guest.”) In this case, the host operating system provides the guest with resources such as memory and processor time. Another such technique is the use of an “exokernel.” An exokernel manages certain devices (e.g., the processor and the memory), and also manages certain types of interaction between the operating systems, although an exokernel—unlike a VMM—does not virtualize the entire machine. Even when an exokernel is used, it may be the case that one operating system (e.g., the “main” operating system) provides much of the infrastructure for the other, in which case the main operating system can still be referred to as the “host,” and the smaller operating system as the “guest.” Both the hosting model and the exokernel model allow useful types of interaction between operating systems that support sharing of infrastructure.
However, even when sharing of infrastructure is desirable, there is a particular type of limited-purpose operating system that presents a challenge when infrastructure is being shared: the “high-assurance” operating system, which will be referred to herein as a “nexus.” A “high assurance” operating system is one that provides a certain level of assurance as to its behavior. For example, a nexus might be employed to work with secret information (e.g., cryptographic keys, etc.) that should not be divulged, by providing a curtained memory that is guaranteed not to leak information to the world outside of the nexus, and by permitting only certain certified applications to execute under the nexus and to access the curtained memory. Since the expectation that the nexus will behave according to its specification may be higher than the expectations imposed on the main operating system, the nexus should not interact with the main operating system in any way that would allow events happening at the main operating system to compromise the behavior of the nexus. In this sense, a problem is how to allow different operating systems to interact usefully in a way that supports the sharing of infrastructure, without allowing one operating system to compromise the behavior of another.
While the foregoing describes the problem of allowing operating systems to interact with each other, it will be appreciated that an operating system is merely one type of environment that may need to interact with other environments (or need to be isolated from other environments) to a greater or lesser degree. In greater generality, the problem can be viewed as how two entities can interact with each other when at least one of the entities is, in some respect, distrustful of the actions of another entity.
In view of the foregoing there is a need for a system that overcomes the drawbacks of the prior art.